Your CVSS Questions Answered – IT Governance UK Blog
What the Common Vulnerability Scoring System is, how to use it, limitations and alternatives, and key changes in CVSS v4.0
Our senior penetration tester Leon Teale has more than ten years’ experience performing penetration tests for clients in various industries all over the world. In addition, he’s won hackathon events in the UK and internationally, and is accredited for multiple bug bounties.
Previously, we’ve interviewed Leon about secure remote working and what the best VPN (virtual private network) solutions are. More recently, we got his insights into the ‘mother of all breaches’, which saw more than 26 billion records leaked.
Today, we’re chatting to him about the CVSS (Common Vulnerability Scoring System), finding out more about:
- What the framework is;
- Who should use it and when;
- How a penetration tester uses the framework;
- Whether it’s suitable to use in risk assessments;
- The limitations of the CVSS, and whether there are any suitable alternatives; and
- Key changes introduced in the latest version of the framework, CVSS v4.0, and when v4.0 will be adopted.
What is the CVSS?
The CVSS is a globally recognised framework that allows for a universal, standard scoring system for software vulnerabilities. It aims to generate a severity rating based on the vulnerability’s total score [composed of different metrics – more on these later], which is done in ‘bands’.
In both CVSS v3.X and v4.0, the severity rating bands are:
- Critical
- High
- Medium
- Low
- Informational
Note: The respective scores for these bands are 9.0–10.0, 7.0–8.9, 4.0–6.9, 0.1–3.9 and 0.
Who should use the CVSS, and when?
As the CVSS is globally recognised, most industry standards and publicly available security assessment tools use it. Most security professionals and companies provide CVSS scores alongside any vulnerabilities they find when performing a security assessment.
So, whether you’re a developer using a web application scanning tool to assess your own work, or a systems administrator doing your monthly due diligence checks with a vulnerability scanner, or a third-party security company performing a penetration test, you’re likely to use the CVSS.
That’s because this framework allows identified issues to be put into perspective, and prioritised accordingly.
Can organisations use the CVSS to help them conduct risk assessments and generally measure risks? Why or why not?
The CVSS can help in a risk assessment, but it’s designed to be used as a baseline score to determine severity, not risk.
That said, you can adjust the metrics to fit the environment it’s being used in. So, while most organisations will take the score and associated severity band [critical, high, etc.], some organisations will choose to use their own ‘risk matrix’.
For example, if a vulnerability is identified and has a score of, say, 4.2, this would typically be a medium-risk finding – but if an organisation has its own risk matrix, it may consider any score above, say, 3.5 a medium risk [even though 3.5 is normally low].
This sort of thing is common among organisations that must satisfy regulatory or contractual requirements, such as the PCI DSS [Payment Card Industry Data Security Standard]. Typically, you’d only expect a critical or high severity rating to be a significant issue – but for PCI DSS compliance, it’s possible that medium and low severity findings may be deemed significant.
One example is TLS [Transport Layer Security]. If an organisation uses TLSv1.0, it’d be non-compliant with the PCI DSS, even though the CVSS considers it a medium-risk vulnerability [under both CVSS v3.X and v4.0].
In short, organisations can use the CVSS to assess the severity of a vulnerability, but without further context outside of that score, it won’t define the risk to the organisation.
When you’re using the CVSS as a penetration tester, do you use your discretion to up- or downgrade a risk? If so, under what circumstances would you consider doing this?
It’s quite common for a penetration tester to use their judgement to adjust the risk.
When you’re using a CVSS calculator to determine the overall score of a vulnerability, sometimes it puts the severity at medium or even high, when you feel there are mitigating factors that lower the risk, and thus the severity of the finding. The tester may then downgrade the vulnerability.
In such cases, when the tester writes up their report, they should clearly state that although the score of the identified vulnerability is medium, the overall risk has been reduced because of X, Y and Z. That way, should that decision be questioned later, the tester can justify their reasoning.
There may also be scenarios where the tester isn’t certain, for example due to a lack of information. They may also make a mistake. In such cases, three things can happen:
- The tester uses the higher-risk option. This is safer than potentially underselling a vulnerability and running the risk of the finding being dismissed.
- The tester gets the missing information by talking to the client, so they can provide a more appropriate – and true – reflection of the risk.
- The client queries or even disputes a reported vulnerability’s severity, and offers additional information. The tester should then update the report with the relevant information to keep a record.
What are the limitations of the CVSS?
For a start, as previously mentioned, the CVSS measures severity, not risk. This is due to the limited information that is provided and used to generate the CVSS score.
Both CVSS v3.X and v4.0 are split into metric groups, of which we [assessors] use the ‘base score’ the most. To generate that score, we look at impact – so confidentiality, integrity and availability – and exploitability. That covers things like the attack vector [from where the vulnerability can be exploited], the attack complexity, the privileges required to exploit it, whether the attacker would need a user to interact with them, and the scope [can you access that system/data only, or does it then give you further access?].
In terms of other limitations, while the CVSS does its best to have many metrics that generate the overall score of a vulnerability, it can still be somewhat subjective or not quite clear as to what a metric should be set to. This can lead to discrepancies between the different assessors generating the scores.
Also, for v3.1 and earlier, the CVSS works better for some technologies than others. For instance, vulnerabilities in a standard server, such as for a data centre or website, are relatively easy to score. However, that scoring system works less well for newer technologies like the IoT [Internet of Things] and the Cloud. This makes it harder to directly compare and prioritise vulnerabilities in different technologies, but may also give a less accurate reflection of the true risk.
For instance, the severity might come out as high, but should actually be lower because you’re dealing with an embedded system.* Or you might be dealing with the reverse: a low severity on, say, an IoT device that cannot be upgraded or manually configured, making it difficult to secure it, thus increasing the risk.
*IoT and similar devices have ‘embedded systems’. This is different from, say, laptops. Embedded systems require different patches to regular machines or may not have patches at all. Either way, this can increase the severity of a vulnerability according to the CVSS. However, the risk can often be mitigated by locking down or restricting the device, and isolating it from the internal domain and corporate machines.
Are there alternatives to the CVSS we should consider?
While there isn’t really a direct alternative to the CVSS – at least, not one that uses a fundamentally different system – there are other frameworks and tools that, in certain circumstances, can be better choices than the CVSS.
One example is the CWE [Common Weakness Enumeration]. This framework – with its own scoring system – focuses on software and its various weaknesses, such as improper input validation, memory safety and access control.
There is also the EPSS [Exploit Prediction Scoring System], which is a machine learning model that can help predict the likelihood of a vulnerability being exploited. Again, this uses its own scoring system.
I personally have never used or referenced the EPSS, but to give you an example of when you might use this – suppose that I tested a local sandwich shop’s website and found it to be using SSL or TLS with medium-strength ciphers, rather than the recommended high strength. The CVSS would score this as a medium vulnerability.
I’d then use my best judgement and adjust the metrics [the ones used to generate the overall score of a vulnerability] to get this to a low severity, largely because the likelihood of someone exploiting this vulnerability for this website is so low. For an attacker, it wouldn’t be worth the resource and time necessary to exploit it, considering the very little to no benefit to them. In this type of situation, using a framework like the EPSS can complement the CVSS by providing an additional severity rating.
So, a new version of the CVSS was recently released. Why was the update necessary?
As cyber security evolves, so should these frameworks, to improve accuracy and relevance.
Often, feedback from security professionals and companies will play a part in these updates, so that any issues or inconsistencies can be addressed in the new version – after all, they’re the ones using it.
In the case of the CVSS, user feedback made clear that the scoring system needed to be more granular. Some of the metrics also had to be reworded to make them less open to interpretation, to ensure that more consistent scores are generated from different assessors. Plus, we needed metrics that’d work for technologies like IoT and the Cloud.
In short, most limitations I highlighted earlier are being addressed in v4.0.
Can you take us through CVSS v4.0’s key changes?
One key change is the new base metrics, particularly attack requirements [assessing the specific conditions needed to be able to exploit the vulnerability], though the user interaction metric has also been refined [whether a user needs to interact with the attacker before the vulnerability can be successfully exploited].
There’s also an improved impact assessment framework that distinguishes between the vulnerable and the subsequent systems – so the systems that’d be directly compromised if the vulnerability was exploited, and the systems the attacker may gain access to from there.
Another thing worth noting is the greater emphasis on operational technology, the IoT and industrial control systems, largely due to the continuous changes to, and complexity of, modern-day cyber security.
The FIRST website provides a useful overview of all key changes.
From your perspective, as a penetration tester, does this change much?
I don’t think so. When we adopt the new CVSS, the method of obtaining the score will still be the same. That said, we’ll have to learn exactly what each of the metrics mean to ensure we give the most accurate and useful score possible.
Do you feel that any of the updates require more clarification?
Honestly, at this stage, I can’t answer that, as I haven’t really started using it yet. We’ll have to wait and see whether we come across practical difficulties when we do start to use it properly. I’ll let you know.
From when will CVSS v4.0 start to be used? And when will the previous version, CVSS v3.1, be retired?
Officially, CVSS v4.0 launched on 1 November 2023. But as to when will people start adopting it – that’s a different matter.
I’d expect security companies to start to adopt v4.0 this year, but don’t be surprised if you’re still receiving reports based on v3.1 or even v3.0 for another couple of years from your security providers. They’ll want to be sure there’s no blowback due to changing the severity of a vulnerability between different versions of the CVSS.
Furthermore, the tools that calculate these scores need to be updated first, which can be more complicated than most people think. It’s not just a matter of changing some metrics, but often involves changes to the user interface or display, and other less obvious changes that often require a lot of manual work. This takes time.
I don’t believe there’s a specific retirement date for v3.1, but it’s important that professionals and organisations continue to clearly identify which scoring system version they’re using.
Learn more about penetration testing
Penetration testing – conducted by a qualified, experienced assessor like Leon – is a valuable addition to any cyber security project, including one based around an ISO 27001 ISMS (information security management system) – specifically, as part of your ISO 27001 risk assessment.
Penetration testing establishes whether the security in place to protect a network or an application against external threats is adequate and functioning correctly.
Our free green paper Penetration Testing and ISO 27001 – Securing your ISMS explains further how penetration testing fits into an ISO 27001 ISMS project.
We hope you enjoyed this week’s edition of our ‘Expert Insight’ series. We’ll be back next week, chatting to another expert within the Group.
In the meantime, if you missed it, check out last week’s blog, where cyber incident responder Vanessa Horton gave us her expert insights into anti-forensics techniques.
